The present invention relates to a method, device utilizing an electronic graphical representation of a monetary system for implementing electronic money payments as an alternative medium of economic exchange to cash, checks, credit and debit cards, and traditional electronic funds transfer. The system according to the present invention utilizes electronic representations of money that are designed to be universally accepted and exchanged as economic value by subscribers of the monetary system.
Currently, approximately 350 billion monetary transactions occur between individuals and institutions annually. The extensive use of monetary transactions has limited the automation of individual transactions such as purchases, fares, and bank account deposits and withdrawals. Individual cash transactions are burdened by the need to have the correct amount of cash or providing change therefor. Furthermore, the handling and managing of paper cash and coins is inconvenient, costly, and time consuming for both individuals and financial institutions.
Although checks may be written for any specific amount up to the amount available in the account, checks have very limited transferability and must be supplied from a physical inventory. Paper-based checking systems do not offer sufficient relief from the limitations of cash transactions, sharing many of the inconveniences of handling currency while adding the inherent delays associated with processing checks. To this end, economic exchange is moving toward automation for greater convenience at a lower cost.
Automation is being used for large transactions through computerized electronic funds transfer (“EFT”) systems. ETF is essentially a process of value exchange achieved through the banking system's centralized computer transactions. EFT services are a transfer of payments utilizing electronic “letters of credit” and are used primarily by large commercial organizations. The American Clearing House (ACH), where a user can enter a pre-authorized code and download information with billing occurring later, and Point Of Sale (POS) systems, where transactions are processed by connecting with a central computer for authorization for the transaction granted or denied immediately, are examples of EFT systems that are utilized by retail and commercial organizations.
Home banking bill payment services are another example of EFT systems used by individuals to make payments from a home computer. Currently, however, home banking initiatives have found few payors. Less than one percent of bank payors use service accounts for transfers and information, using personal computers over telephone lines. One reason that home banking has not been a successful product is because the payor cannot deposit and withdraw money as needed in this type of system. Another reason home banking initiatives have found few payors is the inherent distrust in the security of data transmission of financial data across the Internet 100 prevalent in society given the present Internet 100 security and encryption products currently available to the general public.
Current EFT systems, credit cards, or debit cards, which are used in conjunction with an online system to transfer money between accounts, such as between the account of a merchant and that of a payor, do not satisfy the need for an automated transaction system providing an ergonomic interface.
To implement an automated, convenient transaction that can dispense some form of economic value, there has been a trend towards off-line payments. For example, numerous ideas have been proposed for some form of “electronic money” that can be used in non-cash payment transactions as alternatives to the traditional currency and check types of payment systems. Best known of these are magnetic stripe cards purchased for a given amount and from which a prepaid value can be deducted for specific purposes. Upon exhaustion of the economic value, the cards may be thrown away. Other examples include memory cards or so called smart cards, which are capable of repetitively storing information representing value that is likewise deducted for specific purposes. These methods also do not satisfy the current needs for a consumer friendly, convenient and secure electronic transaction system.
The Internet has become a valuable tool for the electronic transfer of information, which can include financial transactions. It is possible and desirable for a computer operating under the control of the payor over a publicly accessible packet-switched network (e.g., the Internet) to bi-directionally share payment information with a computer operated under the control of a payee, without risking the exposure of the information to interception by third parties that have access to the network, and to assure that the information is from an authentic source. It is further desirable for this information, including a subset of the information provided by the payor, to be provided to the payee by the security server system that is designated by a bank or other financial institution that has the responsibility of providing payment on behalf of the payor, without the risk of exposing that information to interception by third parties. Such institutions may include, for example, merchants or financial institutions.
One such attempt to provide such a secure transmission channel is a secure payment technology such as Secure Electronic Transaction (hereinafter “SET”), jointly developed by the Visa and MasterCard card associations, and described in Visa and MasterCard's Secure Electronic Transaction (SET) Specification, Feb. 23, 1996, hereby incorporated by reference. Other such secure payment technologies include Secure Transaction Technology (“STT”), Secure Electronic Payments Protocol (“SEPP”), Internet Keyed Payments (“IKP”), Net Trust, and Cybercash Credit Payment Protocol. One of ordinary skill in the art readily comprehends that any of the secure payment technologies can be substituted for the SET protocol without undue experimentation.
Such secure payment technologies, referenced above, require the payor to operate software that is compliant with the secure payment technology, interacting with third-party certification authorities, thereby allowing the payor to transmit encoded information to a payee, some of which may be decoded by the payee, and some which can be decoded only by an institution specified by the payor.
Another such attempt to provide such a secure transmission channel is a general-purpose secure communication protocol such the Secure Sockets Layer (hereinafter “SSL”). SSL provides a means for secure transmission between two computers. SSL has the advantage that it does not require special-purpose software to be installed on the payor's computer because it is already incorporated into widely available software that many people utilize as their standard Internet access medium. Other examples of general-purpose secure communication protocols include Private Communications Technology (“PCT”) from Microsoft, Inc.; Secure Hyper-Text Transport Protocol (“SHTTP”) from Terisa Systems; Shen; Kerberos; Photuris; and Pretty Good Privacy (“PGP”) all of which meet the IPSEC criteria. One of ordinary skill in the art readily comprehends that any of the general-purpose secure communication protocols can be substituted for the SSL transmission protocol without undue experimentation. However these protocols have proven to be vulnerable to attack, therefore greater security must be available.
Banks desire an Internet payment solution that functions similar to existing Point of Sale (POS) applications that are currently installed on their host computers and require minimal changes to their host systems. This is a critical requirement since any downtime for a bank's host computer system represents an enormous expense. Currently, there are over fourteen hundred different payment-related applications available. The large number of applications is necessary to accommodate a wide variety of host message formats, diverse methods for communicating to a variety of hosts with different dial-up and direct-connect schemes, and different certification around the world.
Internet-based payment solutions require additional security measures that are not found in conventional POS or EFT terminals. This additional requirement is necessitated because Internet communication is done over publicly accessible unsecured communication line in stark contrast to the private, secure, dedicated phone or leased line service utilized between a traditional payee and an acquiring bank. Thus, it is critical that any solution utilizing the Internet for a communication backbone employs some form of secure cryptography.
As discussed above, the current state-of-the-art in Internet based payment processing is a protocol referred to as SET, or Secure Electronic Transaction. Since the SET messages are uniform across all implementations, banks cannot differentiate themselves in any reasonable way. Also, since SET is not a proper superset of all protocols utilized today, there are bank protocols that cannot be mapped or translated into SET because they require data elements for which SET has no placeholder. Further, SET only handles the message types directly related to authorizing and capturing credit card transactions and adjustments to these authorizations or captures. In a typical EFT terminal in the physical world, these messages comprise almost the entire volume of the total number of messages between the payee and the authorizing bank, but only half of the total number of different message types. These message types, which are used infrequently, but which are critical to the operation of the EFT terminal must be supported for proper transaction processing.
Generally, applications written for this field are written using JAVA, C, and/or the C++ languages and utilize object oriented programming methodology. Object oriented programming (OOP) has become increasingly used to develop complex applications. As OOP moves toward the mainstream of software design and development, various software solutions require adaptation to make use of the benefits of OOP.
OOP is a process of developing computer software using objects, including the steps of analyzing the problem, designing the system, and constructing the program. An object is a software package that contains both data and a collection of related structures and procedures. Since it contains both data and a collection of structures and procedures, it can be visualized as a self-sufficient component that does not require other additional structures, procedures or data to perform its specific task. OOP, therefore, views a computer program as a collection of largely autonomous components, called objects, each of which is responsible for a specific task. This concept of packaging data, structures, and procedures together in one component or module is called encapsulation.
In general, OOP components are reusable software modules that present an interface that conforms to an object model and that are accessed at run-time through component integration architecture. Component integration architecture is a set of architecture mechanisms that allow software modules in different process spaces to utilize each other's capabilities or functions. This is generally done by assuming a common component object model on which to build the architecture.
It is worthwhile to differentiate between an object and a class of objects at this point. An object is a single instance of the class of objects, which is often just called a class. A class of objects can be viewed as a blueprint, from which many objects can be formed.
OOP allows the programmer to create an object that is a part of another object. For example, the object representing a piston engine is said to have a composition-relationship with the object representing a piston. In reality, a piston engine comprises a piston, valves and many other components; the fact that a piston is an element of a piston engine can be logically and semantically represented in OOP by two objects.
OOP also allows creation of an object that “depends on” another object. If there are two objects, one representing a piston engine and the other representing a piston engine wherein the piston is made of ceramic, then the relationship between the two objects is not that of composition. A ceramic piston engine does not make up a piston engine. Rather it is merely one kind of piston engine that has one more limitation than the piston engine; its piston is made of ceramic. In this case, the object representing the ceramic piston engine is called a derived object, and it inherits all of the aspects of the object representing the piston engine and adds further limitation or detail to it. The object representing the ceramic piston engine “depends from” the object representing the piston engine. The relationship between these objects is called inheritance.
When the object or class representing the ceramic piston engine inherits all of the aspects of the objects representing the piston engine, it inherits the thermal characteristics of a standard piston defined in the piston engine class. However, the ceramic piston engine object overrides these ceramic specific thermal characteristics, which are typically different from those associated with a metal piston. It skips over the original and uses new functions related to ceramic pistons. Different kinds of piston engines have different characteristics, but may have the same underlying functions associated with it (e.g., how many pistons in the engine, ignition sequences, lubrication, etc.). To access each of these functions in any piston engine object, a programmer would call the same functions with the same names, but each type of piston engine may have different/overriding implementations of functions behind the same name. This ability to hide different implementations of a function behind the same name is called polymorphism and it greatly simplifies communication among objects.
With the concepts of composition-relationship, encapsulation, inheritance and polymorphism, an object can represent just about anything in the real world. In fact, our logical perception of the reality is the only limit on determining the kinds of things that can become objects in object-oriented software. Some typical categories are illustrated as follows: objects can represent physical objects, such as automobiles in a traffic-flow simulation, electrical components in a circuit-design program, financial transactions in an economics model, or aircraft in an air-traffic-control system; objects can represent elements of the computer-user environment such as windows, menus or graphics objects; an object can represent an inventory, such as a personnel file or a table of the latitudes and longitudes of cities; or an object can represent user-defined data types such as time, angles, and complex numbers, or points on the plane.
Programming languages are beginning to fully support the OOP principles, such as encapsulation, inheritance, polymorphism, and composition-relationship. With the advent of the C++ language, many commercial software developers have embraced OOP. C++ is an OOP language that offers a fast, machine-executable code. Furthermore, C++ is suitable for both commercial-application and systems-programming projects. For now, C++ appears to be the most popular choice among many OOP programmers, but there is a host of other OOP languages, such as Smalltalk, common lisp object system (CLOS), and Eiffel. Additionally, OOP capabilities are being added to more traditional popular computer programming languages such as Pascal.
The development of graphical user interfaces began to turn procedural programming arrangements inside out. These interfaces allow the user, rather than program logic, to drive the program and decide when certain actions should be performed. Today, most personal computer software accomplishes this by means of an event loop that monitors the mouse, keyboard, and other sources of external events and calls the appropriate parts of the programmer's code according to actions that the user performs. The programmer no longer determines the order in which events occur. Instead, a program is divided into separate pieces that are called at unpredictable times and in an unpredictable order. By relinquishing control in this way to users, the developer creates a program that is much easier to use. Nevertheless, individual pieces of the program written by the developer still call libraries or objects provided by the operating system to accomplish certain tasks, and the programmer must still determine the flow of control within each piece after it's called by the event loop. Application code still “sits on top of” the system.
Even event loop programs require programmers to write a lot of code that should not need to be written separately for every application. The concept of an application framework carries the event loop concept further. Instead of dealing with all the nuts and bolts of constructing basic menus, windows, and dialog boxes and then making these things all work together, programmers using application frameworks start with working application code and basic user interface elements in place. Subsequently, they build from there by replacing some of the generic capabilities of the framework with the specific capabilities of the intended application.
Application frameworks reduce the total amount of code that a programmer has to write from scratch. However, because the framework is really a generic application that displays windows, supports copy and paste, and so on, the programmer can also relinquish control to a greater degree than event loop programs permit. The framework code takes care of almost all event handling and flow of control, and the programmer's code is called only when the framework needs it (e.g., to create or manipulate a proprietary data structure).
A programmer writing a framework program not only relinquishes control to the user (as is also true for event loop programs), but also relinquishes the detailed flow of control within the program to the framework. This approach allows the creation of more complex systems that work together in interesting ways, as opposed to isolated programs, having custom code, being created over and over again for similar problems.
Thus, as is explained above, a framework basically is a collection of cooperating classes of objects that make up a reusable design solution for a given problem domain. It typically includes objects that provide default behavior (e.g., for menus and windows), and programmers use it by inheriting some of that default behavior and overriding other behavior so that the framework calls application code at the appropriate times. There are three main differences between frameworks and class libraries:
Behavior versus Protocol. Class libraries are essentially collections of behaviors that you can call when you want those individual behaviors in your program. A framework, on the other hand, provides not only behavior but also the protocol or set of rules that govern the ways in which behaviors can be combined, including rules for what a programmer is supposed to provide versus what the framework provides.
Call versus Override. With a class library, the programmer codes objects and calls their member functions. It's possible to code and call objects in the same way with a framework (i.e., s to treat the framework as a class library), but to take full advantage of a framework's reusable design, a programmer typically writes code that overrides and is called by the framework. The framework manages the flow of control among its objects. Writing a program involves dividing responsibilities among the various pieces of software that are called by the framework rather than specifying how the different pieces should work together.
Implementation versus Design. With class libraries, programmers reuse only implementations, whereas with frameworks, they reuse design. A framework embodies the way a family of related programs or pieces of software work. It represents a generic design solution that can be adapted to a variety of specific problems in a given domain. For example, a single framework can embody the way a user interface works, even though two different user interfaces created with the same framework might solve quite different interface problems.
Thus, through the development of frameworks for solutions to various problems and programming tasks, significant reductions in the design and development effort for software can be achieved.
To date, Web development tools have been limited in their ability to create dynamic Web applications that span from client to server and inter-operate with existing computing resources. Until recently, HTML has been the dominant technology used in development of Web-based solutions. However, HTML has proven to be inadequate in the following areas: poor performance; restricted user interface capabilities; lack of interoperability with existing applications and data; inability to scale, and weak security.
Sun Microsystem's Java language solves many problems by: improving performance; enabling the creation of dynamic, real-time web applications; and providing the ability to create a wide variety of user interface components.
With Java, developers can create robust User Interface (UI) components. Custom “widgets” (e.g. real-time stock tickers, animated icons, etc.) can be created, and performance is improved. Unlike HTML, Java supports the notion of validation, offloading appropriate processing onto the client for improved performance. Dynamic, real-time Web pages can be created. Using the above-mentioned custom UI components, dynamic Web pages can also be created.
Sun's Java language has emerged as an industry-recognized language for “programming the Internet.” Sun defines Java as: “A simple, object-oriented, distributed, interpreted, robust, secure, architecture-neutral, portable, high-performance, multithreaded, dynamic, buzzword-compliant, general-purpose programming language. Java supports programming for the Internet in the form of platform-independent Java applets.” Java applets are small, specialized applications that comply with Sun's Java Application Programming Interface (API) allowing developers to add “interactive content” to Web documents (e.g. simple animations, page adornments, basic games, etc.). Applets execute within a Java-compatible browser (e.g. Netscape Navigator or Internet Explorer) by copying code from the server to client. From a language standpoint, Java's core feature set is based on C++. Sun's Java literature states that Java is basically “C++, with extensions from Objective C for more dynamic method resolution”.
Another technology that provides similar function to JAVA is provided by Microsoft and ActiveX Technologies, to give developers and Web designers the wherewithal to build dynamic content for the Internet and personal computers. ActiveX includes tools for developing animation, 3-D virtual reality, video and other multimedia content. The tools use Internet standards, work on multiple platforms, and are being supported by over 100 companies. The group's building blocks are called ActiveX Controls, small, fast components that enable developers to embed parts of software in hypertext markup language (HTML) pages. ActiveX Controls work with a variety of programming languages including Microsoft Visual C++, Borland Delphi, Microsoft Visual Basic programming system and Microsoft's development tool 10 for Java, code named “Jakarta.” ActiveX Technologies also includes ActiveX Server Framework, allowing developers to create server applications. One of ordinary skill in the art readily recognizes that ActiveX could be substituted for JAVA without undue experimentation to practice the invention.